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Requirements 


"In spite of appearances, people seldom know what 
they want until you give them what they ask for. " 
— Donald Gause and Gerald Weinberg, 
Are Your Lights On? 
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Requirements Overview ce ile 
= Anti-Patterns: 
e Requirements arent written down . nei 
e Requirements incomplete, imprecise 
pe . \ FBI Virtual Case 
e ‘Be like last version, except... 
File project 
terminated 
= Requirements = Requirements issues: 


Requirements faults can defeat a 
design before it is even built 


Describe what system does 

— Also what it’s not supposed to do 
Precise, testable language 

— Each requirement traces to system test 


Requirements not defined when 
development contract signed 


e “We will know it when we see it” 
e Repeated requirements changes 
e Scope creep (new requirements 


added) of 80% 
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Characteristics of Good Requirements Ue hersty 





m Precise and minimally constrained 
e Describes what system should do, not how it does it 


e Uses “shall” to require an action; “should” to state a goal 
e If possible has a numeric target instead of qualitative term 


— Has tolerance (e.g., 500 msec +/- 10%, “less than X”) 
=m Traceable & testable 
e Each requirement has a unique label (e.g., “R-7.3”) 
e Each requirement cleanly traces to an acceptance test 
e Requirement satisfaction has a feasible yes/no test 
= Supported within context of system 
e Supported by rationale or commentary 
e Uses consistent terminology 
e Any conflicting requirements resolved or prioritized 





Ui <P —R1 E—>_ '*T 1 
U2 <> R2 |S > 12 
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Problematic Requirements pee 
Untraceable (no label) at i a 
e System shall shut down when E-STOP is activated. ‘ee’ = ie =i \ Bae 
Untestable ; Ce 
e R-1.1: System shall never crash 
Imprecise 


e R-1.7: The system provides quick feedback to the user. 
No measurement tolerance 

e R-2.3: LED shall flash with a period of 500 msec 
Overly complex 


e R-7.3: Pressing the red button shall activate Widget X, while 
pressing the blue button should cause LED Z to blink instead — 
of LED Y illuminating steadily, which would be accomplished via the yellow pultton. 
Describes implementation 


e R-8.3: Pressing button W shall cause two 16-bit integer values to be added, then ... 
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' Requirements Ambiguity Tae hn 


= A requirements engineer gets a text message: 
“On the way home, please pick up one carton of milk. 


And if they have eggs, get six.” 


= The requirements engineer comes home with: 
6 cartons of milk and no eggs. 


= Spouse: “Why did you buy six cartons of milk?!" 





= Requirements Engineer: “They had eggs.” 


Adapted from: www.ganssle.com/jokes.htm. © 2921 Philip Koopman 6 
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Extra-Functional Requirements Mellon 


University 





= Emergent properties (things hard to attribute to one component) 
e Performance, real-time deadlines 
e Security, Safety, Dependability in general all Way) iy 
e Size, Weight and Power consumption (“SWaP”) Sa 
— Often handled with an allocation budget across components B 
e Forbidden behaviors (“shall not do X”) 
— Often in context of safety requirements 


— “Safety function” is a way to ensure a negative 
behavior, but some behaviors are emergent 













a 
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"| CITY ORD. 13.40.030 





=m Design constraints 
e Must meet a particular set of standards 
e Must use a particular technology 
e System cost, project deadline, project staffing 






https://goo.gl/hT3nDU 
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Product vs. Engineering Requirements — Unitrin 


= Product level requirements: 
what the product does 





e Example: 
“PR6. The clock shall support a user-settable audible alarm.” 


e Gives a feature list of what the product actually does 
e Can be the interface between marketing and engineering 


= Detailed functional/engineering requirements: 
how the product actually works 
e Example: “R5. Time set buttons shall change the alarm set time.” 
e Embedded systems often have detailed requirements tied to operational modes 
— “R5. In Alarm Set Mode the time set buttons shall change the alarm set time.” 


— “R6. Pressing the “+’ time set button shall increase time value by one minute per button 


press according to the current set mode.” 
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~Requirements Approaches tech 





Text document with list of requirements 

e Works best if domain experts already know reqts. 
e Over time, this can converge to OK regts. 

UML Use Cases 

e Different activities performed by actors 


e Requirements are scenarios attached 
to each use case 


Agile User Stories 

e Each story describes a system interaction 
Functional decomposition 

e Start with primary system functions 


e Make more and more detailed lists of sub- 
functions (creates a “functional architecture”) 


Prototyping to elicit requirements 
e Customers know it when they see it 
e Sometimes a paper mock-up is enough 


Customer 













Soda Machine 


U1. Customer 
inserts a quarter 


U2. Customer pushes 
a soda button 


U3. Customer pushes 
coin return button 


U4. Observe soda 
availability 


UML Use Case Diagram 
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Requirements Templates (EARS) a 


m Easy Approach to Requirements Syntax (Mavin et al.) e.g.:_https://bit.ly/2CQSF37 


g [While/Where <precondition>] [when/if <trigger> then] 


<system> shall <response> 
Ubiquitous: The touch screen shall have a response time of less than 250 msec. 
State-driven: WHILE an external speaker is connected, the internal speaker shall mute. 
Event-driven: WHEN a card is inserted, the card reader shall verify credentials. 


Optional feature: WHERE a convertible roof is installed, a park/roof motion interlock 
function shall be provided. 


Unwanted: IF an invalid value is entered THEN an error message shall be displayed. 
Complex: combinations of the above 


= Requirements issues to avoid: 


Ambiguous, vague, complex, omitted, duplicated, wordy, implementation, untestable 
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Example Software Regugmhens ja 


Communications, Navigation, and Networking reConfigurable Testbed (CoNNeCT) Project 


} ~ Document No... GRC-CONN-REQ-0084 
Title: Software Requirements Specification Effective Date. 02/23/2010 Page 18 of 61 





Parent Req | ReqID Requirement Text and Rationale Prior Allocated i> 
GRC-CONN-REQ-0084 
EFFECTIVE DATE: 02/23/2010 


National Aeronautics and FSRD-3714 The Software shall send data at a user data rate from 
Space Administration wa 7 zero up to and including 100 Mbps. 


Rationale: The maximum data rate the Payload 
Avionics Software must send is 100 Mbps. Lower 
rates must also be handled. 


FSRD-3133 The software shall send and receive data on two 
SpaceWire channels simultaneously at up to the 
maximum SDR interface data rate (full duplex) that 


can be sustained by both SDRs. 


Rationale: When communicating with multiple 
radios, the Software will need to sustain an 
achievable data rate. In this requirement, it is 
defined as the minimum data rate of the two (or 
three, if possible) SDRs involved in the experiment. 
For instance, this data could be provided in the 
routing table. If two other radios are involved, then 
the data rate may change, based on the capability of 
those two radios (i.e. a new minimum interface data 
rate). This value should not be hard coded, but 
should have the capability for change, once on-orbit. 
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Best Practices for Requirements a, 
=m Six C-terms for Good Requirements J — UEADIGHTS ONO 
e Clear, Concise, Correct, C rat thar 
Coherent, Complete and Confirmable 
= Also: 


e Deal with extra-functional issues 

e Relate requirements to design flow 
— Associate with user stories or use cases 
- Trace to corresponding test 

= Requirements pitfalls ae Seto 

e Avoid unnecessary details and implementation 

e If its missing from requirements, it won't get done 

e If its not testable, you won't know if it got done Ge. ed 





WE NEED TO MAKE 500 HOLES IN THAT LWALL, 
50 T'VE BUILT THIS AUTOMATIC DRILL. ITUSES 
ELEGANT PRECISION GEARS TO CONTINUALLY 
ADIUST ITS TORQUE AND SPEED AS NEEDED 


GREAT, IT'S THE PERFECT WEIGHT! 
WE'LL LOAD 500 OF THEM INTO 
THE CANNON WE MADE AND 
HOOT THEM AT THE WALL. 





HOW SOFTWARE DEVELOPMENT WORKS 


https://xked.com/2021/ 


